SMART TRANSLATION OF GENERIC CONFIGURATIONS 



TECHNICAL FIELD OF THE INVENTION: 

The present invention relates to computer networks, and more particularly to 
improvements in management of vendor-specific policies in networks. 
BACKGROUND: 

5 In a computer network, each device or application has a vendor-specific 

configuration. Fxmctional areas, such as a firewall, application access rule, etc., are 
managed by tools written and designed by each vendor. Typically, each functional area is 
managed by tools that are unique to the particular vendor or device. Some devices are 
controlled by a vendor-specific CLI (Command Line Interface) and others are controlled 

10 by a vendor-specific API (Application Programming Interface). 

Firewalls attempt to protect networks fi^om unauthorized access and hostile 
exploitation or damage to computers connected to the network. Firewalls provide a 
server through which all access to the network must pass. Firewalls are centralized 
systems that require administrative overhead to maintain. 

15 An access control Ust (ACL), generally, is a data structure that defines who has 

access to a single specified object stored on a computer or network. More specifically, an 
ACL typically indicates the access rights each user or group has. Access rights for file 
objects typically include the right to read a file, write the file, delete the file, and execute 
the file. Examples of objects to which ACLs may refer include files, directories, 

20 subdirectories, web services, computer resources, and the like. In known ACL-based 
systems, each object includes a security attribute that identifies its corresponding ACL. 
Typically the metadata for each object points to its corresponding ACL. 

Many policies may be managed in a network. Access control, quality of service, 
backup, and availability are possible policies that may be monitored in a network, each 

25 managed by tools that are unique to the particular vendor or device. 

In a large network, or in a network with several devices and applications fi-om 
different vendors, it is difficult to manage the different devices and applications. The 
network can be managed by writing extensive code, usually in C or Java, to translate each 
vendor-specific configuration into one vendor-agnostic configuration. Then, when a new 

30 device or application is added to the network, additional code must be written to add the 
new configuration of the device or application to the existing code, creating one vendor- 
agnostic or non-vendor-specific configuration. Each revision of code is lengthy, 
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requiring the time to code and test, before the new device or application may be properly 
managed in the network. 

Accordingly, a need exists for a technique with which vendor-specific tools can be 
automatically translated into a single vendor-agnostic configuration. 
5 SUMMARY: 

The present mvention is directed to a system and method for implementing a 
policy in a network, the network having a device-agnostic policy implementation; a 
plurality of network devices, at least two of the devices being dissimilar; and a plurality 
of device translators, each device translator corresponding to a respective one of the 

10 plurality of network devices, at least two of the device translators being dissimilar, each 
of the plurality of device translators translating the device-agnostic policy implementation 
into corresponding device-specific implementations. 
DESCRIPTION OF THE DRAWINGS: 

The features, aspects, and advantages of the present invention will become better 

15 understood with regard to the following description, appended claims, and accompanying 
drawings where: 

FIGURE 1 depicts a system configuration of an embodiment of the present 
invention; and 

FIGURE 2 depicts a flowchart showing the operation of an embodiment of the 
20 present invention. 

DETAILED DESCRIPTION: 

The present invention is a system and methodology of using a vendor independent 
representation of a device or application in a particular fimctional area, such as a firewall, 
an application access rule, etc., and writing a smart translator to transform the vendor 
25 independent configuration into a vendor-specific CLI (Command Line Interface) or to 
generate a vendor-published API (Application Programming Interface). 

In general, a document may be encoded in SGML (Standard Generalized Markup 
Language) or an SGML derivative. Examples of SGML derivatives are HTML 
(HyperText Markup Language) and XML (Extensible Markup Language). HTML is a 
30 subset of SGML that is directed toward document interchange, and is primarily a 
publishing language. XML is a simplified version of SGML, tailored to structured 
document content. 

When a user wishes to print or display an XML document, the software (i.e. the 
parser, compiler or other application) processes the contents of the XML document. The 
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software may be an XSL (Extensible Stylesheet Language) stylesheet, which can be 
designed to create a viewable version of the XML document, or can be designed to use or 
manipulate the XML document. 

HTML and XML are tag languages, where specially-designated constructs 
5 referred to as "tags" are used to delimit (or "mark up") information. In the general case, a 
tag is a keyword that identifies what the data is which is associated with the tag, and is 
typically composed of a character string enclosed in special characters. "Special 
characters" means characters other than letters and numbers, which are defined and 
reserved for use with tags. Special characters are used so that a parser processing the data 

10 stream will recognize that this a tag. A tag is normally inserted preceding its associated 
data: a corresponding tag may also be inserted following the data, to clearly identify 
where that data ends. As an example of using tags, the syntax "<p>" in HTML indicates 
the beginning of a paragraph. In XML, "<email>" could be used as a tag to indicate that 
the character string appearing in the data stream after this tag is to be treated as an e-mail 

15 address; the syntax "</email>" would then be inserted after the character string, to delimit 
where the e-mail character string ends. 

XML is an "extensible" markup language in that it provides users the capability to 
define their own tags. This makes XML a very powerfiil language that enables users to 
easily define a data model, which may change fi-om one document to another. When an 

20 application generates the tags (and corresponding data) for a document according to a 
particular XML data model and transmits that document to another application that also 
understands this data model, the XML notation fiinctions as a conduit, enabling a smooth 
transfer of information from one application to the other. By parsing the tags of the data 
model from the received document, the receiving application can re-create the 

25 information for display, printing, or other processing, as the generating application 
intended it. Conversely, HTML uses a particular set of predefined tags, and is therefore 
not a user-extensible language. 

XML is a well-formed notation, meaning that all opening tags have corresponding 
closing tags (with the exception of a special "empty" tag, which is both opened and 

30 closed by a single tag, such as "<email/>"), and each tag that nests within another tag is 
closed before the outer tag is closed. HTML, on the other hand, is not a well-formed 
notation. Some HTML tags do not require closing tags, and nested tags are not required 
to follow the strict requirements as described for XML (that is, in HTML a tag may be 
opened within a first outer tag, and closed within a different outer tag). 
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With respect now to FIGURE 1 of the Drawings, there is represented an system 
diagram showing a network, generally designated by the reference numeral 100, as 
utilized in an embodiment of the present invention. As shown in FIGURE 1, there are 
abstract policy definitions 110, vendor independent policy implementations 120, 
5 translators 130, and specific devices 140. The diagram generally depicts the interaction 
of the various components, as will be explained in more detail hereinbelow. 

As shown in FIGURE 1, the policy definitions 110 may be several policy 
definitions, here chosen to be access control 1 12, quality-of-service 1 14, backup 116, and 
availability 118. It should be understood that the policy definitions 110 may include 

10 other definitions than these. For the purposes of illustration, only access control 1 12 is 
used to describe the present invention, although it should be understood that the present 
invention may be applied to all of the policy definitions 110, as well as other policy 
definitions. The vendor independent policy implementations 120 may be a firewall 122, a 
VPN (Virtual Private Network) 124, J2EE (Java 2, Enterprise Edition) Application 126, 

15 and an operating system 128, govemed by a custom policy 129. The custom policy 129 is 
imported through a translator to properly configure the operating system 128. For the 
purposes of illustration, only the firewall 122 is used to describe the present invention, 
although it should be understood that the present invention may be applied to all of the 
access control policies 120. The vendor independent firewall 122 may be implemented 

20 through Cisco PIX ACL 142, through Checkpoint API 144, or through Nortel ACL 146. 
Each specific device 140 has a corresponding translator 130 that produces a device- 
specific API or ACL, i.e., translator 132 produces ACL 142 for the Cisco PIX, translator 
134 produces an API for Checkpoint, and translator 136 produces ACL 146 for Nortel. 

With reference now to FIGURE 2, there is shown a flowchart depicting the flow 

25 of an embodiment of the present invention. Initially, a non- vendor-specific configuration 
is represented using XML (step 205). Next, a translator is built using XSL for each type 
of policy and specific vendor or device (step 210). Then, the type of device and vendor is 
identified from XML (step 215). The specific translator is dynamically loaded (step 220). 
Output is generated in vendor-specific format by translating the XML (step 225). 

30 In this embodiment, it should be imderstood that once the translators for each type 

of policy and specific vendor or device is written in XSL, then the addition or 
maintenance of any policy or specific device is govemed a by simple, non-vendor- 
specific XML file. Various illustrations of embodiments of the present invention are 
shown hereinbelow. 
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A high-level illustration of an XML file in policy management that extracts 
information for each policy type is shown below. 



<policy type="micidleware"> 
5 <app name="ciatabase" cost="300"> 

<time response=="8" availability="99"> 

</app> 
</policy> 

10 A corresponding XSL file that extracts information for each type is shown. 



<xsl : template match="app"> 

"<xsl : value-of select="@name"/>", 
<xsl : value-of select="@cost"/>, 
15 <xsl:apply-teinplates select="time"/> 

</xsl : template> 



The XML file is translated, using the XSL file, to produce a corresponding Java API, as 
shown. 

20 

Application . newlnstance 
("database", 300, 8, 99) 

The above XML, XSL, and Java code show a simple illustration of using XML to define 
25 a policy and then translate it into Java, using XSL rather than writing the particular Java 
code. In this way, non-vendor-specific XML files can be made for various devices, 
v^thout tailoring the XML code to a particular vendor. The XML file is then translated, 
using a particular XSL translator, into vendor-specific code, here a Java API. 

A high-level illustration of an XML file in policy management, specifically for 
30 use with a firewall for a Cisco PIX, is shown. 



<policy type="security"> 

<fw id="655" name="perimeter" type="fw"> 
<allow> 

<service id="servicel04" naine="telnet" protocol="3" 
port="23" seq="l"> 

<from ip="15.4.28.100" mask="255 . 255 . 248 . 0"/> 
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<to ip="104.3.30.20" inask="255 . 255 . 248 . 0"/> 
</service> 
</allow> 

</fw> 
5 </policy> 

A corresponding XSL file that extracts information, specifically for use with a firewall for 
a Cisco PIX, is shown. 

10 <xsl: template match="fw"> 

<xsl : f or-each select="*/allow"> 

access-list act_group permit 
<xsl : apply-templates select="service'V> 
</xsl : f or-each> 
15 </xsl : template> 

The above XML file is translated into corresponding Cisco PIX CLI using the XSL file. 
The resulting file is shown. 

20 access-list act_group permit 

telnet 23 15.4.28.100 104.3.30.20 

The above XML, XSL, and CLI code is a simple illustration of using XML to define a 
policy and then translate it into CLI, using XSL rather than writing the particular CLI 
25 code. As above, non- vendor-specific XML files can be made for various devices, without 
tailoring the XML code to a particular vendor. The XML file is then translated, using a 
particular XSL translator, into vendor-specific code, here a Cisco PIX CLI. 

Another high-level illustration of an XML file in policy management, specifically 
for use with a firewall for Load-balancer, is shown. 

30 

<policy type="security"> 

<fw id="655" nanie="perimeter" type="fw"> 
<allow> 

<service id="servicel04 " name="telnet" protocol="3" 
35 port="23" seq="l"> 

<from ip="15.4.28.100" niask="255 . 255 . 24 8 . 0"/> 
<to ip="104 .3.30.20" mask="255 . 255 . 248 . 0'V> 
</service> 
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</allow> 

</fw> 
</policy> 

5 A corresponding XSL file that extracts information, specifically for use with a firewall for 
Load-balancer, is shown. 

<xsl : template mat ch==" f w"> 

<xsl : f or-each select="*/allow"> 
10 access-list act_group permit 

<xsl : apply-templates select="service"/> 
</xsl : f or-each> 
</xsl : template> 

15 The above XML file, when translated using the XSL file, produces corresponding 
Foundry Serverlron CLI, as shown. 

access-list 102 permit telnet 
15.4.28.100 104.3.30.20 23 log 

20 

The above XML, XSL, and CLI code is a simple illustration of using XML to define a 
policy and then translate it into CLI, using XSL rather than writing the particular CLI 
code. As shown, non-vendor-specific XML files can be made for various devices, 
without tailoring the XML code to a particular vendor. The XML file is then translated, 
25 using a particular XSL translator, into vendor-specific code, here Foundry Serverlron 
CLI. 

The foregoing description of the present invention provides illustration and 
description, but is not intended to be exhaustive or to limit the invention to the precise 
one disclosed. Modifications and variations are possible consistent with the above 
30 teachings or may be acquired fi-om practice of the invention. Thus, it is noted that the 
scope of the invention is defined by the claims and their equivalents. 
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